home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Amiga Tools 3
/
Amiga Tools 3.iso
/
grafik
/
raytracing
/
rayshade-4.0.6.3
/
inetray
/
faq
< prev
next >
Wrap
Text File
|
1993-08-17
|
4KB
|
74 lines
======================================================================
F A Q
doc: Fri Apr 24 14:58:47 1992
dlm: Tue Aug 17 16:52:34 1993
(c) 1992 ant@ips.id.ethz.ch
uE-Info: 10 57 T 0 0 72 3 2 8 ofnI
======================================================================
Q: I get the message ``Warning: stderr is lost!'' in the messages file.
A: Recompile everything with the NOASYNCIO_QUIRK defined.
Q: When I issue an inetray or an inetray.ping I get a a dot every few
seconds and the program does not seem to proceed.
A: There is either another process using the same socket running on your
machine (another inetray, maybe), or the servers didn't terminate
normally on your last session. You can check by issuing netstat -f
inet.
If there are still workers running on remote machines, you just have
to wait roughly one minute to give them time to shut down orderly; if
another program uses the same port, you have to add a resultport:
definition to your ~/.inetrayrc.
Note that inetray and inetray.ping will just continue trying on the
port, printing a dot every few seconds until the problem disappears
(which eventually will).
Q: Why does inetray need so much more memory than rayshade?
A: There are several reasons for this:
a) The dispatcher needs a lot of memory since it has to buffer a
whole frame. Rayshade does not have to buffer a whole frame since
it renders strictly sequentially.
b) The dispatcher furthermore reads the input file and builds up the
geometry data. This feature allows printing of the error and
warning messages before the rendering actually starts (and cloggs
the syslogs on the worker machines). The memory could and should
be freed after checking the input before allocating the frame
buffer but this is not done at the moment.
c) On every worker machine the inputfile is read and geometry built
up for every used CPU - if you use more than one CPU you need more
memory. This simplifies the handling of multiple CPUs greatly:
every CPU can be viewed as simply another machine. No special code
is required.
d) The actual work is handled by a forked process. This process is a
copy of the server process and contains all geometry data.
Therefore, 2 copies of all data exist for each CPU used. This
solution is quite ugly in terms of memory but very nice in terms
of simplicity. Without forking a new process, process controls
(basically sending remote signals) would be very hard if at all
possible without changing the rayshade source. The parent must
keep the memory because it will fork further workers later on.
Q: I don't seem to be able to ignore a host from my ~/.inetrayrc file.
A: add ignore: name, where name is the exact(!) string as printed by
inetray.ping.
Q: I had problems in the last session and now there seem to still be
servers/workers running and/or connections open.
A: Issue an inetray.kill in the same directory where you started the
problem session. All what's left running after that should kill
itself after roughly a minute anyway.
Q: I think Inetray is a great program and I want to send loads'a money
to the author to thank him.
A: Do so: Andreas Thurnherr, Birkenstr 3, 8640 Rapperswil, Switzerland.
Q: When I trace, workers register correctly but suddenly I get a lot of
messages about lost connections.
A: The workers terminated while reading and processing the input-files.
Check for error messages in your syslog (or in your temp-directory if
NOASYNCIO_QUIRK is set). Usually the files are not there or not
accessible for the user under which the servers are running. Note
that files like /tmp are usually there on every machine but they are
different even on machines which share there filesystems.